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Echtzeitwartung einer relatlonalen Dat:ezxbazik 

Die Erfindung betrifft ein Verfahren zur zeitnahen Wartung 
von Datenbankinhalten, insbesondere von Dateien (Data 
Sets), einer relationalen Datenbank, insbesondere DB2 . Die 
Erfindung betrifft dariiber hinaus eine Vorrichtung 
eingerichtet zur Durchfiihrung eines solchen Verfahrens, ein 
Computerprogramm fiir ein solches Verfahren und ein 
Computerprogratnmprodukt mit einem solchen Verfahren. 

Die Erfindung betrifft das Gebiet der relationalen 
Datenbanken, insbesondere der Datenbank DB2 von 
International Business Machines (IBM) , auf dem 
Betriebssystem OS/3 90 oder z/OS, andere Betriebssysteme 
sind ebenfalls inbegriffen. Bei einer relationalen 
Datenbank wie der DB2 von IBM werden die Daten in einer 
Vielzahl von Indizes und Tabellen verwaltet. Die Daten 
selbst sind physikalisch durch Data Sets represent iert und 
auf einem Speichermedium abgelegt. Die Position, Struktur 
und Grosse der Data Sets wird beim Betrieb der Datenbank 
durch Lese-/Schreibzugrif f e verandert . Die Datenbank greift 
auf Data Sets zu und verandert diese dadurch sowohl 
benutzergesteuert als auch aufgrund interner 
Arbeitsvorschrif ten. Aufgrund der Anderungen sind an den 
Data Sets Wartungsarbeiten fur die Realisierung besserer 
Zugrif f szeiten und Wiederherstellungszeiten notwendig. Die 
Datenbanken halten fiir solche Wartungsarbeiten integrierte 
Wartungsfunktionen (Werkzeuge) bereit, mit deren Hilfe 



Wartungsarbeiten an den Data Sets durchgefuhrt werden 
konnen . 

Bei der Wartung sind verschiedene Werkzeuge von Bedeutung. 
Das ist zum einen die Sicherung der Data Sets, die ein 
Wiederherstellen der Daten ermoglicht. Dies ist dann 
notwendig, wenn die Daten aufgrund von Fehlf unkt ionen der 
Maschine, des Betriebsystems oder der Datenbank selbst oder 
aufgrund von fehlerhaf ten Programmen oder fehlerhaf ten 
Benutzereingaben korrupt oder verlustig sind. Ein 
notwendiges Sichern der Daten wird durch ein 
Datenbankwerkzeug ermoglicht . 

Daruber hinaus ist die Reorganisation der Daten wichtig. 
Durch den Betrieb der Datenbank verschiebt diese aufgrund 
von internen Bearbeitungsregeln die Daten innerhalb der 
Data Sets, um einen schnellen Zugriff auf die Daten zu 
gewahrleisten . Die Verschiebung erfolgt vorzugsweise nach 
logischen Kriterien, so dass zueinander gehorige Daten auch 
physikalisch nebeneinander gespeichert werden. Nach 
langerer Betriebsdauer ist eine gute Organisation der Daten 
jedoch durch eine Vielzahl von Verschiebungsoperat ionen 
nicht mehr gewahrleistet . Die Datenbank hat durch das 
betriebsbedingte Umorganisieren einen Zustand der Unordnung 
geschaffen, der schnelle Zugriff szeiten auf die Daten 
verhindert. Um diese wieder gewahrleisten zu konnen, miissen 
die Daten ab einem gewissen Grad der Unordnung wieder 
reorganisiert werden. Auch hierzu stellt die Datenbank ein 
eigenes Werkzeug zur Verfugung. 

Auch ist das Sammeln von Statistiken uber den Zustand der 
Daten innerhalb der Data Sets eine wichtige Aufgabe 
innerhalb von Datenbanken. Bei Abfrage von Daten durch eine 



Anwendung ermittelt die Datenbank die optimale 
Zugrif f sstrategie auf die Daten mit Hilfe dieser 
Statistiken. Durch die Statist iken ist ein Einblick in den 
internen Ablauf der Datenbank moglich/ 

Bei DB2 sind obige Werkzeuge COPY, REORG und RUNSTATS.. Aber 
auch weitere Werkzeuge sind bei der Durchfuhrung der 
Wartungen an den Data Sets moglich. Bei DB2 sind dies 
insbdsondere die Werkzeuge MODIFY und QUIESCR. 

Zur Durchfuhrung der Wartungsarbeiten werden die Werkzeuge 
mit Hilfe der dafiir bestimmten Befehle aktiviert. Die 
Befehle werden in Stapeldateien (Batch Jobs) , die der 
sogenannten Job Control Language (JCL) unterliegen, 
abgelegt und abgearbeitet , wenn die Datenbank nicht 
ausgelastet ist. Aufgrund der standigen Veranderung der 
Zahl und Inhalt der Data Sets ist as notwendig, dass die 
Befehle dynamisch erstellt werden und an den jeweils 
bestehenden Datenstand angepasst werden. 

Bei herkommlichen relationalen Datenbanken werden die 
Zustande der Data Sets mit Hilfe externer Programme 
ermittelt und mit Hilfe der ermittelten Zustande die 
notwendigen Werkzeuge fur die Wartung mit den 
entsprechenden Befehlen aktiviert. Die Uberwachung der 
Zustande mit Hilfe externer Programme hat den Nachteil, 
dass diese die Systemleistung negativ beeinf lussen, da 
diese Uberwachungsprogramme viele Systemressourcen 
benotigen. Daruber hinaus sind diese Programme 
f ehleranf allig, da sie auf die bestehende Datenbank 
aufsetzen und nicht in diese integriert sind. Bei 
Anderungen der Datenbankf unktionen und Strukturen mussen 
die externen Programme daran angepasst werden. 



Es ist das Bestreben von Datenbankbetreibern, eine hohe 
Verf ugbarkeit der Datenbanken 24 Stunden am Tag fur sieben 
Tage die Woche bereit zu stellen. Eine 24x7 Verf ugbarkeit 
von Datenbanken im GrolSrechnerbereich bedeutet durchgangig 
gute Antwortzeiten (etwa durch zeitnahe Reorganisat ionen 
und zeitnahes Sammeln von Stat ist iken fiir stets optimierten 
Datenzugrif f ) , stetige Vermeidung von Fehlern (durch 
zeitnahes Reagieren auf kritische Situationen) , schnelle 
Recovery- Zeiten bei Storungen (etwa durch zeitnahe 
Sicherungen) , sowie eine nur unwesentliche Beeintracht igung 
der Anwendungen durch Wartungsarbeiten . Dies erfordert 
jedoch, dass die Uberwachung und die Wartung der Datenbank 
in nahezu Echtzeit erfolgt. Aufgrund der intensiven 
Systemauslastung durch die externen Uberwachungsprogramme 
konnen diese nicht andauernd die Datenbank liberwachen. 
Dariiber hinaus fiihrt die periodische Uberwachung der 
Datenbank durch die externen Programme, die heutzutage in 
Perioden von vielen Stunden bzw. Tagen durchgefiihrt wird, 
dazu, dass danach eine Vielzahl von Wartungsarbeiten 
anstehen. Nach den Uberwachungslauf en werden die Befehle 
fur die Werkzeuge generiert und in einer Datei fur die 
Stapelverarbeitung abgelegt. Die Datei wird anschliessend 
an einen Job Scheduler ubergeben. Der Job Scheduler ist so 
eingestellt, dass er die Wartungsbef ehle in bestimmten 
Zeitfenstern aktiviert, die fur die Wartung reserviert sind 
und danach die Abarbeitung der Befehle liberwacht. Durch die 
Vielzahl von Wartungsarbeiten in diesen Zeitfenstern durfen 
Anwendungen nicht oder nur eingeschrankt auf der Datenbank 
arbeiten. Vorrangig haben die Wartungswerkzeuge den 
Zugriff auf die Datenbankinhalte . Das allerdings fuhrt 
dazu, dass die Datenbank nicht immer uneingeschrankt zur 



Verfiigung steht und die Anwendungen zu manchen Zeiten 
keinen Zugriff auf die Daten haben. . 

Der Erfindung liegt somit das technische Problem zugrunde, 
die durchgangige Verf ugbarkeit bei gleichzeitiger 
kontinuierlicher Wartung einer relationalen Datenbank zur 
Verfugung zu stellen. 

Das zuvor hergeleitete technische Problem wird 
erf indungsgemalS durch ein Verfahren zur zeitnahen Wartung 
von Datenbankinhalten, insbesondere von Dateien (Data 
Sets), einer relationalen Datenbank, insbesondere DB2 , 
gelost', bei welchem mit Hilfe einer datenbankintegrierten 
Zustandsiiberwachung Zustande der Datenbankinhalte erfasst 
werden, bei welchem Zustandsdaten der erfassten Zustande 
mit Hilfe der datenbankintegrierten Zustandsiiberwachung 
zeitnah ausgegeben werden, bei welchem die ausgegebenen 
Zustandsdaten analysiert und mit Vergleichsdaten verglichen 
werden und bei welchem Wartungsf unktionen im Wesentlichen 
unmittelbar nach einem positiven Vergleichsergebnis 
aktiviert werden. 

Mit Hilfe der datenbankintegrierten Uberwachung, die im 
Falle der DB2 als Real Time Statistics (RTS) realisiert 
ist, ist eine laufende Uberwachung der Zustande der Data 
Sets bei geringer Systembelastung moglich. Die RTS 
externalisiert die gesammelten Zustandsdaten in 
einstellbaren Intervallen in dafiir vorgesehene Tabellen. 
Die Intervalle werden erf indungsgemaS klein eingestellt, so 
dass eine zeitnahe Ausgabe der Zustandsdaten ermoglicht 
wird. Zeitnah umfasst einen Zeitraum von wenigen Minuten 
bis hin zu einigen Stunden, So ist beispielsweise eine 
Ausgabe nach 30 Minuten bzw. nach 1 Stunde vorteilhaft. 



Erf indungsgemaS sind jedoch auch grossere bzw. kleiner 
Zeitraume moglich. Dies ist abhangig von den Anf orderungen 
an die Datenbank bezuglich Sicherung, Datenreorganisation 
bzw, Sammeln von Statist iken uber Daten. 

Die ausgegebenen Zustandsdaten werden erf indungsgemaS 
unmittelbar ausgewertet und die Befehle zur Aktivierung der 
notwendigen Werkzeuge bei Bedarf erstellt. Dies bangt vom 
Zustand der Data Sets ab. Um erkennen zu konnen, ob eine 
Wartung angezeigt ist oder nicht, werden die Zustandsdaten 
mit Vergleichsdaten verglichen. Die Vergleichsdaten konnen 
Grenzwerte vorgeben, die einen Zustand beschreiben, zu dem 
das Ausfuhren eines Werkzeugs auf dem jeweiligen Data Set 
als notwendig erachtet wird. 

Erf indungsgemaS wird der notwendige Befehl unmittelbar bei 
Erreichen eines bestimmten Vergleichswert erstellt und die 
Wartungsf unktion aktiviert. 

Durch die zeitnahe, datenbankintegrierte Uberwachung der 
Zustande werden notwendige Wartungsarbeiten sofort erkannt 
und konnen unmittelbar ausgefiihrt werden. Dies fuhrt zu 
einer im Wesentlichen gleichmaSigen Belastung der Datenbank 
mit Wartungsarbeiten und die Datenbankinhalte stehen 
lauf end fur die damit arbeitenden Anwendungen zur 
Verfugung. Es ist nicht mehr notwendig, Wartungsf ens ter zu 
definieren, zu denen die Wartungsf unktionen arbeiten und 
die Anwendungen keinen Zugriff auf die Daten haben. Jedoch 
wird daneben auch gewahrleistet , dass der Zustand der Daten 
immer den vorgegebenen Kriterien entspricht und somit bspw. 
Fehler in den Daten oder lange Zugriff szeiten vermieden 
werden konnen . 



Haufig ist eine Wartung von Data Sets nur notwendig, wenn 
ein kritischer Zustand erreicht wurde . Daher wird 
vorgeschlagen, dass die Vergleichsdaten 

Zustandsschwellwerte von Datenzustanden reprasentieren. 
Diese Zustandsschwellwerte geben an, ab wann Daten mit 
Hilfe geeigneter Werkzeuge gewartet werden mussen. Erreicht 
der ermittelte Zustand eines Data Sets den bestimmten 
Zustandsschwellwerte kann die Wartung unmittelbar mit Hilfe 
eines geeignet generierten Befehls aktiviert werden. 

Verschiedene Data Sets bzw. Gruppen von Data Sets 
unterliegen verschiedenen Anf orderungen bezuglich ihres 
Zustandes . Daher wird vorgeschlagen, dass fur Data Sets 
bzw. Gruppen von Data Sets verschiedene Schwellwerte 
festgelegt werden konnen. Auch ist es moglich, das 
unterschiedliche Wartungsf unktionen bei unterschiedlichen 
Datenzustanden angezeigt sind, so dass vorgeschlagen wird, 
unterschiedliche Zustandsschwellwerte fur verschiedene 
Wartungsf unktionen einzustellen. 

Der Zustand der Daten verandert sich wahrend des Betriebes 
der Datenbank laufend. Dabei kann sich der Datenzustand 
allmahlich verschlechtern . Es wird daher auch 
vorgeschlagen, dass zumindest ein barter und zumindest ein 
weicher Zustandsschwellwert eingestellt wird. Bei Erreichen 
des weichen Zustandsschwellwertes ist eine Wartung der 
Daten mit Hilfe der geeigneten Wartungsf unkt ion nicht 
unbedingt angezeigt, ware jedoch sinnvoll. Somit kann eine 
Wartung noch von weiteren Kriterien abhangig gemacht 
werden, wie bspw. die aktuelle Systemauslastung, der GroiSe 
der Data Sets, der Zustand anderer Daten oder die aktuelle 
Zeit. Andererseits kann bei Erreichen des harten 
Zustandsschwellwertes eine Wartung der Daten nicht mehr 



aufgeschoben werden, da ansonsten massive Datenfehler, hohe 
Zugrif f szeiten oder Datenverlust drohen. In diesem Fall 
soil die Wartung unmittelbar , bedingungslos aktiviert 
we r den . 

Es ist auch denkbar, dass die unmittelbare Ausfuhrung der 
Wartungsf unktionen durch anwendungsspezif ische Vorgaben 
Oder anderer Anf orderungen an die Datenbank unterbunden 
werden sollte. Daher wird vorgeschlagen, dass Restriktionen . 
bestimmbar sind, zu denen die unmittelbare Aktivierung der 
Wartungsf unktionen verhindert wird. In diesem Fall wird die 
Wartungsf unkt ion vorzugsweise unmittelbar nach Wegfall der 
Restriktionen ausgef lihrt . 

GemaS einer bevorzugten Ausfuhrung kann der unmittelbar 
erstellte Befehl zur Aktivierung der Wartungsf unkt ion die 
direkte Ausfuhrung der Funktion bewirken (Ubergabe an JES, 
Job Entry System) . Auch kann der Befehl an einen Job 
Scheduler libergeben werden. Dies ist insbesondere dann 
sinnvoll, wenn Wartungen nach dem herkommlichen Prinzip 
durchgef lihrt werden sollen. Die Wartung wird dann vom Job 
Scheduler durchgef lihrt und liberwacht . Dabei ist es j edoch 
moglich, bei der Ubergabe des Befehls an den Job 
Schelduler, diesen anzuweisen, den Befehl unmittelbar 
auszufiihren, Dann wird die Ausfuhrung nicht durch den Job 
Scheduler anhand der dort vorliegenden Bestimmungen 
ausgelost, jedoeh vom Job Scheduler liberwacht. Schliesslich 
ist es auch moglich, den Befehl an eine Datenbankprozedur 
unmittelbar zu libergeben. Dies ist im Fall der. DB2 der 
Aufruf der DB2 Stored Procedure DSNUTILS. 

Durch eine Protokollierung der Wartungsf unktionen konnen 
anstehende, zur Zeit laufende und in der Vergangenheit 



ausgefuhrte Wartungsf unktionen liberwacht werden. Der 
Wart ungszust and der Datenbank ist ermittelbar . Ausserdem 
kann bei einem Fehler bei der Wartung ermittelt werden, 
welche Funktion fehlerhaft war und diese erneut aktiviert 
Oder terminiert werden. 

Ein weiterer Gegenstand der Erfindung ist eine Vorrichtung 
zum Ausfuhren eines vorher beschriebenen Verfahrens, mit 
einer Datenbankeinheit zum Betreiben einer relationalen 
Datenbank, wobei die Datenbankeinheit Wartungsmittel zum 
Ausfuhren von Wartungsf unktionen aufweist und 
Uberwachungsmittel zum Uberwachen und Ausgeben von 
Zustandsdaten iiber Zustande von in der Datenbankeinheit 
.gespeicherten Datenbankinhalten aufweist, mit einer 
Uberwachungseinheit zum Uberwachen der ausgegebenen 
Zustandsdaten, wobei die Uberwachungseinheit Mittel zum 
Analysieren der Zustandsdaten und zum Vergleichen der 
Zustandsdaten mit Vergleichsdaten aufweist und wobei die 
Uberwachungseinheit Ausgabemittel zum unmittelbaren 
Ausgeben eines Aktivierungsbef ehls fur die Aktivierung der 
Wartungsmittel zum Durchfiihren einer Wartungsf unkt ion 
aufweist . 

Die Erfindung betrifft daruber hinaus auch ein 
Conputerprogramm mit einer Implementierung eines vorher 
beschriebenen Verfahrens fur einem Computer und auch ein 
Computerprogrammprodukt mit einem solchen Computerprogramm 
Oder mit Anweisungen zur Durchfiihrung eines vorher 
beschriebenen Verfahrens. 
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Die Erf indung wird nachf olgend anhand einer ein 

Ausf uhrungsbeispiel zeigenden Zeichnung naher- erlautert . In 

der Zeichnung zeigt die einzige Figur: 

Fig. 1 ein Ablauf diagratnm eines erf indungsgemaEen 
Verf ahrens . 

Dargestellt ist ein Ablauf diagramm eines erf indungsgemaSen 
Verf ahrens . Im Weiteren wird auf die Bezeichnungen 
innerhalb der DB2 von IBM zuriickgegrif f en. Die Erfindung 
ist jedoch fur jede relationale Datenbank anwendbar. 

Zur iDurchf lihrung des Verf ahrens wird auf Datensatze 2, 4 
und 6 zuruckgegrif f en. Der Datensatz 2 (DSNRTSDB) enthalt 
die von der datenbankintegrierten Funktion Real Time 
Statistics (RTS) ausgegebenen Zustandsdaten . Diese 
Zustandsdaten werden in bestiiranbaren Zeitintervallen, 
vorzugsweise halbstiindlich, ausgegeben. DSNRTSDB 2 enthalt 
zwei Tabellen SYSIBM. TABLESPACESTATS 2a und 

SYSIBM.INDEXSPACESTATS 2b. Diese Tabellen 2a, 2b enthalten 
die Zustande der Data Sets, die Tabellen speichern, und die 
Zustande der Data Sets, die Indizes speichern. Die in 
DSNRTSDB 2 enthaltenen Daten sind mit Hilfe von SQL- 
Abfragen zuganglich. Die enthaltenen Daten sind 
insbesondere die Inf ormationen liber: 

- Die Grosse der einzelnen Data Sets; 

- Anderungen an den Data Sets seit dem let z tern COPY; 

- Anderungen an den Data Sets seit dem letztem REORG; 

- Anderungen an den Data Sets seit dem letztem RUNSTATS. 

Die datenbankintegrierte Funktion RTS beansprucht nur 
wenige Ressourcen und die Datenbanklei stung leidet nicht 
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unter dem stetigen Bereitstellen der Zustandsdaten in den 
RTS Tabellen. 

Der Datensatz 4 (DSNACCOR) enthalt eine Tabelle 4a 
(DSNACC.EXCEPT_TBL) die anwendungsspezif ische und 
datenbankspezif ische Ausnahmen enthalt. Diese Ausnahmen 
konnen sich auf Restriktionen bezuglich der Ausfuhrung der 
Wartungsf unktionen beziehen. Die Tabelle DSNACC . EXCEPT_TBL 
4a enthalt sowohl bezuglich einzelner Werkzeuge als auch 
bezuglich bestinunter Data Sets Restriktionen. Diese 
Restriktionen mussen bei der Aktivierung der 
Wartungsf unktionen berucksichtigt werden und konnen so 
eventuell das linmittelbare Auslosen der Wartungsf unktionen 
beeinf lussen . 

Schliesslich enthalt der Datensatz 6 (RTM DB) zwei Tabellen 
6a und 6b. Die Tabelle 6a (RTM.Threshold^Rules) enthalt 
Vergleichswerte, die fur einen Vergleich zwischen einem 
Zustand einzelner Data Sets mit Sollzustanden dienen. Die 
Schwellwerte sind dabei in harte Schwellwerte und weiche 
Schwellwerte unterteilt. Das Erreichen eines harten 
Schwellwertes bewirkt das unmittelbare, bedingungslose 
Aktivieren eines Werkzeuges zur Wartung eines Data Sets, 
wohingegen bei einem weichen Schwellwert noch weitere 
Bedingungen- berucksichtigt werden konnen. 

Der Ablauf des Verfahrens lasst sich wie folgt beschreiben: 

Beim erstmaligen Einschalten ist die Funktion RTS nicht 
initialisiert . Das bedeutet, das Zustandsinf ormationen uber 
COPY, REORG und RUNSTATS erst durch die RTS erfasst und 
externalisiert werden, wenn diese Werkzeuge bei 
eingeschaltetem RTS auf dem jeweiligen Data Set ausgefuhrt 
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worden sind. In diesem Fall wird in der Ausgabe des RTS ein 
Tabelleneintrag fur dieses Data Set initialisiert und bei 
den nachsten Ausgaben berucksichtigt . 

Zur Initialisierung ist es daher moglich, den Zustand der 
einzelnen Data Sets, wahrend des Betriebes bei 
eingeschaltetem RTS, mit Hilfe herkommlicher , externer 
Uberwachungsf unktionen zu ermitteln. Wird durch die 
externen Uberwachungsf unktionen ein Bedarf fur die 
Ausfuhrung eines Werkzeuges festgestellt, wird die 
Ausfiihrung dieses Werkzeuges nach herkommlichen Methoden 
veranlasst . Nach Ausfuhrung des Werkzeuges auf dem 
jeweiligen Data Set ist die RTS hierfiir initialisiert und 
Zustandsveranderungen werden durch RTS erfasst und 
f ortgeschrieben . Die externen Uberwachungsf unktionen mussen 
dieses Data Set nicht mehr liberwachen. Die externe 
Uberwachung wird solange fiir die verbleibenden Data Sets 
fortgesetzt, bis alle Data Sets in der RTS initialisiert 
sind. Zukiinftige Entscheidungen bezuglich des Data Sets und 
des Werkzeuges werden dann mit Hilfe der nachfolgend 
beschriebenen Methode getroffen. 

Zunachst werden im Schritt 10 die Zustandsdaten der Data 
Sets aus der DSNRTSDB 2 gelesen. Dariiber hinaus werden die 
Schwellwerte aus RTM DB 6 und die Restriktionen aus 
DSNACCOR 4 ermittelt. 

Im Schritt 12 werden die Zustandsdaten mit den weichen 
Schwellwerten der RTM DB 4 verglichen. Wenn ein Zustand 
eines Data Sets diesen Schwellwert erreicht hat, wird die 
durchzuf uhrende Wartungsaktion ermittelt. Danach wird 
uberpruft, ob der Wartung dieses Data Sets mit der 
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ausgewahlten Wartungsf unktion eine Restriktion aus dem 
Datensatz DSNACCOR 4 entgegensteht . 

Falls der Schwellwert nicht erreicht wird oder eine 
Restriktion vorliegt, wird im Schritt 14 die Uberwachung 
der Zustande erneut aktiviert . 

Im Schritt 16 werden die harten Schwellwerte aus RTM DB 6 
ermittelt . 

Im Schritt 18 wird uberpriift, ob ein harter Schwellwert 
durch den ermittelten Zustand des jeweiligen Data Sets 
erreicht wurde . 1st dies der Fall, wird unmittelbar eine 
Aktivierung 2 6 der notwendigen Wartungsf unktion 
durchgef uhrt . Liegt der harte Schwellwert nicht vor, 
befindet sich der Zustand des Data Sets zwischen dem 
weichen und dem harten Schwellwert - 

Daraufhin werden in Schritt 2 0 weitere einstellbare 
Restriktionen aus RTM.Execution__Modes 6b ermittelt. 

Im Schritt 22 wird entschieden, ob der Wartung des 
jeweiligen Data Sets mit dem vorgesehen Werkzeug eine 
solche Restriktion entgegensteht. 1st dies der Fall, wird 
in Schritt 24 die Uberwachung der Zustande erneut aktiviert 
und die erroittelten Daten werden fiir weitere Planung und 
Statistiken gespeichert . 

Liegen keine weiteren Restriktionen vor, wird die 
Aktivierung 26 der Werkzeuge durchgef lihrt . Hierbei werden 
Stapelauf trage fur die Wartungswerkzeuge , die der Utility 
JCL unterliegen, erstellt, wobei die Inf ormationen . liber den 
Zustand des zu wartenden Data Sets verwendet werden, Der 
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erstellte Befehl wird in Schritt 26a durch Aufruf der DB2 
Stored Procedure DSNUTILS 28a aktiviert. Im Schritt 26b 
wird der Befehl unmittelbar durch Ubergabe an JES 2 8b 
aktiviert und in Schritt 2 6c wird der Befehl dynamisch an 
den Job Scheduler 28c ubergeben. . Welcher der Schritte 26 
eingeleitet wird, ist einstellbar. Die unmittelbare 
Ausfuhrung des Werkzeuges sollte jedoch bei jedem der dre 
Moglichkeiten gewahrleistet sein. 

Durch die laufende Uberwachung und Wartung der Data Sets, 
wie es erf indungsgemafi vorgeschlagen wird, kann der 
Wartungszustand der Data Sets einer Datenbank optimiert 
werden, ohne dass die Systemlei stung der Datenbank 
wesentlich verringert wird. Insbesondere durch das 
Ausnutzen der datenbankintegrierten Zustandsuberwachung 
(RTS) kann mit wenig Aufwand der Zustand der Data Sets 
uberwacht und bei Bedarf gewartet werden. 
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Patentanspruche 

Verfahren zur zeitnahen Wartung von Datenbankinhalten, 
insbesondere von Dateien, einer relationalen 
Datenbank, insbesondere DB2 , 

bei welchem mit Hilfe einer datenbankintegrierten 
Zustandsuberwachung Zustande der Datenbankinhalte 
erfasst werden, 

bei welchem Zustandsdaten der erfassten Zustande mit 
Hilfe der datenbankintegrierten Zustandsuberwachung 
zeitnah ausgegeben werden, 

bei welchem die ausgegebenen Zustandsdaten analysiert 
und mit Vergleichsdaten verglichen werden und 
bei welchem Wartungsf unktionen im Wesentlichen 
unmittelbar nach einem positiven Vergleichsergebnis 
aktiviert werden. 

Verfahren nach Anspruch 1, dadurch gekennzelchnet, 
dass der Vergleich der Zustandsdaten mit 
Zustandsschwellwerten durchgefuhrt wird, wobei die 
Zustandsschwellwerte Datenzustande reprasentieren, bei 
denen eine Ausfuhrung der Wartungsf unktionen fur die 
jeweiligen Datenbankinhalte angezeigt ist. 

Verfahren nach Anspruch 2, dadurch gekennzexchnet , 

dass die Zustandsschwellwerte fur unterschiedliche 
Datenbankinhalte und/oder Gruppen von 
Datenbankinhalten und/oder verschiedene 
Wartungsf unktionen jeweils eingestellt werden. 



Verfahren nach einem der Anspruche 2 oder 3, dadurch 
gekennzeichziet , dass zumindest ein barter 
Zustandsschwellwert eingestellt wird, dass zumindest 
ein weicher Zustandsschwellwert eingestellt wird, dass 
beim Erreicben des weichen Zustandsschwellwertes die 
Wartungsf unktion beim Vorliegen weiterer Kriterien 
aktiviert wird und dass beim Erreicben des barten 
Zustandsscbwellwertes die Wartungsf unktion unmittelbar 
aktiviert wird. 

Verfabren nach einem der Anspruche 1 bis 4, dadurch 
gekezmzeichziet , dass Restriktionen fur die Ausfiibrung 
von. Wartungsf unktionen system-, zeit-, daten- und/oder 
anwendungsbezogen festgelegt werden, wodurch ein 
unmittelbares Ausfubren einer Wartungsf unktion 
zumindest zeitweise unterbunden wird. 

Verfabren nach einem der Anspruche 1 bis 5, dadurch 
gekennzeichnet , dass die unmittelbare Aktivierung der 
Wartungsfunktionen eine direkte Ausfiibrung, ibre 
Ubergabe an einen Job Scheduler oder einen Aufruf von 
Datenbankprozeduren bewirkt . 

Verfahren nach einem der Anspruche 1 bis 6, dadurch 
gekexmzeichnet , dass die durchgefiihrten 
Wartungsfunktionen protokolliert werden und ein 
Wartungsprotokoll ausgegeben wird, 

Vorricbtung eingerichtet zum Ausfiihren eines 
Verf ahrens nach Anspruch 1 , 

mit einer Datenbankeinbeit zum Betreiben einer 
relationalen Datenbank, 
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- wobei die Datenbankeinheit Wartungsmittel zum 
Ausfuhren von Wartungsfiinktionen aufweist und 

- Uberwachiingsmittel zum Uberwachen und Ausgeben von 
Zustandsdaten uber Zustande von in der 
Datenbankeinheit gespeicherten Datenbankinhalten 
aufweist, ' 

- mit einer Uberwachungseinheit zum Uberwachen der 
ausgegebenen Zustandsdaten , 

- wobei die Uberwachungseinheit Mittel zum Analysieren 
der Zustandsdaten und zum Vergleichen der 
Zustandsdaten mit Vergleichsdaten aufweist und 

- wobei die Uberwachungseinheit Ausgabemittel zum 
unmittelbaren Ausgeben eines Aktivierungsbef ehls fur 
die Aktivierung der Wartungsmittel zum Durchfuhren 
einer Wartungsf unktion aufweist. 

9, Compute rprogramm mit einer Implementierung eines 

Verfahrens nach einem der Anspriiche 1 bis 8 fur einen 
Computer. 

10- Computerprogrammprodukt mit einem Computerprogramm 

nach Anspruch 9 oder mit Anweisungen zur Durchfiihrung 
eines Verfahrens nach einem der Anspriiche 1 bis 8. 
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Zus ainnien£ as sung 



Die Erfindung betrifft ein Verfahren zur zeitnahen Wartung 
von Datenbankinhalten, insbesondere von Dateien (Data 
Sets), einer relationalen Datenbank, insbesondere DB2 . 
Durch ein Verfahren, bei welchem mit Hilfe einer 
datenbankintegrierten Zustandsuberwachung Zustande der 
Datenbankinhalte erfasst werden, bei welchem Zustandsdaten 
der erfassten Zustande mit Hilfe der datenbankintegrierten 
Zustandsuberwachung zeitnah ausgegeben werden, bei welchem 
die ausgegebenen Zustandsdaten analysiert und mit 
Vergleichsdaten verglichen werden und bei welchem 
Wartungsfunktionen im Wesentlichen unmittelbar nach einem 
positiven Vergleichsergebnis aktiviert werden, wird eine 
durchgangige Verfiigbarkeit bei gleichzeitiger 
kontinuierlicher Wartung einer relationalen Datenbank zur 
Verfiigung gestellt. 



Fur die Zusasmenf assung 1st Fig. 1 bestimmt. 



